ETO Development Tools 1/ETO Development Tools 1.iso/Essentials/MacApp Documentation/MacApp AppleLink Messages/MacApp.Tech$ Oct 89/Z0107-Meth Dispatch Detai-Oct89

Text File | 1989-10-17 | 5.8 KB | 126 lines | [TEXT/GEOL]

Item    2793331                         17-Oct-89        07:28

From:   D2079                           Arthur Anderson, M Lockwood,PRT

To:     MACAPP.TECH$                    MACAPP Tech

Sub:    Meth Dispatch Details

Jeff,

Most of the goodies used by the method dispatch mechanism are located in the
%_MethTables CODE segment.

This segment contains a record which contains the name and size of a particular
class.  The record format is as follows:

    ClassID     :   Integer;    {Stored in the first two bytes
                                 of an instance}
    ClassSize   :   Integer;    {Passed to NewHandle when creating
                                 a new instance}
    ClassName   :   MacsBugString;

The ClassName is in the format 'CLASINFO.TOBJECT'.  ClassIDs are always even
numbers to allow for faster access to its super class in the super class table
(described below).  TObject has ClassID = 2.  IfClassA is a subclass of ClassB,
then ClassID(ClassA) > ClassID(ClassB).  This fact is important to the
efficiency of the method dispatching mechanism.

The %_MethTables segment also contains a record for each method which contains
references to the implementations of a method (for example, TView.Draw usually
has several implementations).  This record has the following format:

    JSRInteger          : Integer = $4EBA;  {68000 JSR instruction}
    MethDispatchOffset  : Integer;          {Offset to %_JMPTOTRAP}
    ImplementationCount : Integer;          {# of implementations of this
                                             method}
    CachedClassID       : Integer;          {ClassID saved from last call
                                             for this method}
     CachedImplOffset    : Integer;         {Implementation saved from last
                                             call for this method}
    Array[1..# of implementations] of
            ClassID     : Integer;          {ClassID for this implementation}
            ImplOffset  : Integer;          {A5 relative jump table offset
                                             for this implementation}

When you make a method call, you jump (through the jump table) to this record
on the %_MethTables segment.  The first 4 bytes of the record are a JSR to
%_JMPTOTRAP (See UObject.a). This contains a JMP to the method dispatch code.
The method dispatch code then looks at the return address on the stack to
get a pointer to the rest of the method table.

A handle to the object instance is pushed onto the stack right before
the method call.  The method dispatch code looks at the ClassID (located
in the first two bytes of an object instance) to determine which
implementation to use.  It first looks for an implementation with
the same ClassID as the object. If this is not found, it looks for
implementations for a super class of the object (it uses the super class table,
described below, for this).  To speed things up, the method table is ordered
from most specific to most generic classes, and ClassIDs are ordered by
inheritance as described above.  The ClassID and implementation for the most
recent method call are cached to speed things up when you are making the same
method call several times in a row.  See %_NEWMETHOD in UObject.a for more
information.

The %_JMPTOTRAP trick is used because the location of the method dispatch code
is not determined until run time.  The code is in the 128K and later ROMs,
but must be in RAM for Macs with the 64K ROM.  In MacApp 2.0b9, a few
instructions can be shaved off if the machine has a 68020 or 68030, and in that
case the method dispatch code is also in RAM.

These records are tied together by the super class table and class info table.
These are located at entry point %_CLASSINFO (look at a link map generated by
the linker to find this).

The first two bytes contain the size of the super class table (including these
two bytes).  Following this is an array of ClassIDs.  The ClassIDs are arranged
so that you can compute the super class of a class by using the ClassID as an
offset into the super class table (that's why ClassIDs are even).  For example,
if TView has ClassID = 6, the ClassID of TEvtHandler will be located at offset
6 in the super class table.

Suppose:
    ClassID(TObject) = 2
    ClassID(TEvtHandler) = 4
    ClassID(TView) = 6
    ClassID(TWindow) = 8
    ClassID(TControl) = 10
    ClassID(TCtlMgr) = 12
    ClassID(TDocument) = 14
    ClassID(TApplication) = 16

Then the super class table would look like:

18      {Size of table = 18}
0       {TObject has no super class}
2       {TEvtHandler = OBJECT (TObject)}
4       {TView = OBJECT (TEvtHandler)}
6       {TWindow = OBJECT (TView)}
6       {TControl = OBJECT (TView)}
10      {TCtlMgr = OBJECT (TControl)}
2       {TDocument = OBJECT (TEvtHandler)}
2       {TApplication = OBJECT (TEvtHandler)}

During run time, the location of the super class table is stored in the low
memory global $BEC.

The class info table immediately follows the super class table. The first two
bytes contain the size of the class info table (including these two bytes).
Following this is an array of A5 relative offsets to jump table entries for the
class info records described above.  When you call New(anObject), the ClassID
for the object is passed to MakeNewInstance in UObject.Globals.p.  The ClassID
is used as an offset into the class info table to find the jump table entry for
the class info record for this class.  The size is passed to NewHandle, the
ClassID is stored in the first two bytes of the object, and a new instance is
created.

Last Note:  This information applies to 2.0b9, and earlier versions of MacApp
with the -Opt option set.  It does not apply to the unoptimized dispatching
mechanism used in 2.0b5 and earlier MacApps.

Sorry this is so long.  I hope it is of use or interest to fellow MacAppers.

Mike Lockwood
Andersen Consulting